-
Notifications
You must be signed in to change notification settings - Fork 191
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Jenkins workflows to release -SNAPSHOT builds and to stage releases in maven #187
Conversation
Signed-off-by: dblock <[email protected]>
Signed-off-by: dblock <[email protected]>
We do have it in staging as even though it is successful, a manual intervention is required (as of today) to actually publish the snapshots to maven central. |
Updated. |
jenkins/publish-snapshot.jenkinsfile
Outdated
} | ||
} | ||
stages { | ||
stage('Publish to Maven Staging') { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Rename to Publish to sonatype snapshots repo
or something similar. Quite confusing as maven staging
is actually a maven central staging area
error('Missing REF and/or VERSION.') | ||
} | ||
} | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
do you want to add triggers now or I can create a follow up PR. I have the code ready. Needs few PRs to add creds to jenkins infrastructure.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Let's do a followup.
script { | ||
signArtifacts( | ||
artifactPath: "${ARTIFACT_PATH}", | ||
type: 'maven', |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
My bad. Please do type: 'maven',
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yep. That's what I figured.
Signed-off-by: dblock <[email protected]>
More updates, thx. Let me know if you need anything else. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM!
// checkout the commit | ||
git url: 'https://github.com/opensearch-project/opensearch-java.git', branch: 'main' | ||
sh('git checkout ${REF}') |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
nit: Can be
checkout([$class: 'GitSCM', userRemoteConfigs: [[url: 'https://github.com/gaiksaya/opensearch-java.git']],
branches: [[name: "$ref"]]])
@VachaShah care to +1? Thx |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thank you @dblock!
It might be helpful to also add the details about the release and snapshot workflow in https://github.com/opensearch-project/opensearch-java/blob/main/RELEASING.md may be?
if (version.toString().endsWith("SNAPSHOT")) { | ||
maven("https://aws.oss.sonatype.org/content/repositories/snapshots/") { | ||
name = "snapshotRepo" | ||
credentials(PasswordCredentials::class) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
For my learning, how are these creds passed?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
See above, this asks for a specific environment variable that gets set by the wrapper.
@@ -0,0 +1,25 @@ | |||
pipeline { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
How does the Jenkins fleet pick this job/pipeline ?
Is there a corresponding file in opensearch-ci?
Also I see for every component, jenkins files are defined in opensearch-build
. Why is this different?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
i think the job needs to be added manually once, but I could be wrong (I hope so)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We could move these to OpenSearch-build, I have no strong preference, I was replacing a file that was already here
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah for now we to manually added files, for releasing opensearch-java it already exists. @saratvemulapalli we are planning to move respective jenkins file for clients in their repo. Would be easier to manage. However, need to add regression tests for all jenkins file to see the behavior is as expected.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
thanks that helps :).
One concern having these files in individual repositories is that the responsibility is delegated to the maintainers of the individual projects and make sure the infrastructure is not mis-used.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I believe the maintenance of these files will be delegated to respective maintainers of the project rather than @opensearch-project/engineering-effectiveness being the bottle neck for it. Regarding the mis-use of the infrastructure, we have to be careful what triggers the workflows. For example, if a commit push is gonna trigger the workflow no matter where the workflow lies it will be executed.
Absolutely. @gaiksaya plans to hook this up as a GHA that kicks off this job in Jenkins, and we will need to document how to make the release then (This workflow is in Jenkins because we don’t export credentials Into GHA) |
Actually @dblock , GHA is not in the picture as of now. Was experimenting and we can directly make a release using tags or pushes. |
Description
On top of #186, build locally without maven local, sign, then release to maven staging.
We're misusing
publishToMavenLocal
, that takes a publishable set of artifacts, then actually publishes it to local maven (~/.m2). Then we try to get files from there and make them publishable again (by renaming maven-metadata-local for example). All that is too much work.With this PR you can do
./gradlew --no-daemon publishPublishMavenPublicationToSnapshotRepoRepository
for -SNAPSHOT builds, andVERSION=2.1.0 ./gradlew --no-daemon publishPublishMavenPublicationToLocalRepoRepository
for producing local output that can be signed and uploaded to staging .This just uploads -SNAPSHOTs.
This produces local output which can then be uploaded to staging.
The JenkinsFile was renamed to
jenkins/stage-maven-release.jenkinsfile
to be consistent.See http://jenki-jenki-fpgmrv2ryxko-1366042710.us-east-1.elb.amazonaws.com/job/dblock-opensearch-java-stage-maven-release/4/console for a run that succeeded all the way till uploading to sonatype that requires
SONATYPE_USERNAME
andSONATYPE_PASSWORD
that I believe aren't available in staging (or shouldn't be :)).By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.
For more information on following Developer Certificate of Origin and signing off your commits, please check here.